#Git #Github

learningitbranching 튜토리얼을 해보면서 그동안 한번씩 겪었던 문제들을 해결하는 방법과 기타 세세한 사용방법까지 알게되어 정리하는 글입니다. 한번 꼭 해보세요. git에 관련된 최고의 튜토리얼이였습니다.

1. Git

버전 관리 시스템(Version Control System)이다.
깃허브로 인해서 git에 대한 이미지는 모두 하나씩 마음에 품고 있을 것이라고 생각한다.
Git 관점에서 바라보는 시야를 해석해보는게 더 의미있을 것 같다.

2. Git이 보는 코드 파일은 코드 파일 날것일까?

GitTutorial.java라는 파일이 있다. 이것을 수정한 뒤 깃에 Commit했다. 2번째 버전의 GitTutorial.java가 새로 생성되었을까? 그리고 오리지날인 GitTutorial.java 파일이 따로 아카이브되어있을까? 이래야 이전 버전으로 돌아갔을 때 코드 복구가 가능할 것 같다. GitTutorial.java 파일에 계속 덮어쓰기를 하면 버전관리는 불가능하니까.
이렇게 계속 버전별로 파일을 생성하게되면 언젠가는 매우 덩치가 비대해진 저장공간을 가지게 된다. 그것도 몇년 전 마지막으로 열어본 파일들을 가지고있게되면서.

Git은 이런식으로 파일을 관리하지 않는다. 깃은 아래와 같이 파일을 관리한다.

원본 파일이 있고, 그 파일이 수정되어서 commit이 되면 원본 파일의 어떤 부분이 변했는지 혹은 어떤 위치에 새로 추가되거나 기존의 어떤 부분이 삭제되었는를 포인팅해주는 Delta라는 내용을 새로 저장하게 된다. (Delta는 수학에서 '값의 작은 차'를 나타내는 기호라고 하는데, 이 의미로 사용하지 않았을까 추측해본다.) 즉 commit은 이 delta 스냅샷을 저장한 것이라는 얘기다.

Git이 보는 파일은 파일 날것들의 모음이 아닌 파일과 Commit 세트들의 집합으로 파일을 다룬다.

3. 그럼 Git에게 있어 Branch는?

*위의 그림은 대략적인 개념을 나타낸 그림이다.
이렇게 Branch는 commit들의 집합이라고 생각하면 이해하기 쉬울 것 같다. (브랜치는 참조에 대한 자료구조 저장소(Queue 등)를 의미한다고 이해했다.)

* 2.와 함께 Commit과 Branch를 이렇게 보는게 중요한 이유는, 특정 commit이나 branch를 이런식의 조각 그리고 조각모음으로 생각하게 되면 앞으로 merge나 checkout, cherry-pick등을 이해하는 것이 훨씬 수월해지기 때문이다.

4. Git의 Local & Remote

Git의 Local은 우리 각각의 노트북, Remote는 GitHub같은 서비스가 제공해주는 클라우드라고 생각하면 될 것 같다. Remote는 공유공간, Local은 개인 작업공간이다.
bytebytego에서 만든 이미지가 이를 잘 나타낸다.